\section{Limitations}

%Compared to pure dynamic enforcement techniques~\cite{taintdroid}, 

\ourtool uses static-optimized dynamic enforcement to protect user privacy. This hybrid approach, though bringing in many benefits, is bounded by some inherit limitations of static analysis. More specifically, \ourtool relies on a conservative static analysis to identify safe regions of the code that the privacy policy would never be violated. The current static analysis does not support reflection and dynamic class loading. Consequently, if the app behavior relies on reflection or dynamic class loading, \ourtool may not be able to identify all the potential code paths the app will take, thus compromising its completeness and might introduce false negatives. In addition, the completeness of API summary can affect the results of \ourtool, even though we did not observe such impacts in the evaluated subject programs.
%is critical to the soundness and completeness of the static analysis, including identification of side effect methods and data flow models for APIs.

Another limitation of \ourtool is that its current implementation does not support tracking implicit information flow. One possible way to address this problem is leveraging a more conservative static analysis to identify all possibly affected code fragment (through implicit information flow) as unsafe code and then use dynamic enforcement to ensure its behavior at runtime. However, doing so will inevitably increase \ourtool's runtime overhead. 

Finally, like many existing approaches~\cite{taintdroid,flowdroid}, information flow tracking on the native code portion of the apps is currently not supported. While there are a lot of previous work in this area, due to the existence of pointer arithmetic's, embedding enforcement instructions into the app is often not practical due to high runtime overhead for daily use.

\section{Related Work}

This section discusses closely-related work on
mobile app privacy protection, and
dynamic enforcement in general.

%\sai{one problem in related you should address is that:
%after you discuss a category of existing work, you MUST discuss
%how and in which aspect \ourtool is different. Such discussion is missing in many places below.}

\subsection{Mobile User Privacy Protection}

Mobile user privacy has been an increasingly important problem
as the adoption of mobile devices grows. Existing work in this
area falls into two categories; (1) statically detecting
potential user privacy vulnerabilities, and (2) dynamically
enforcing user privacy policies at runtime.

Static detection techniques~\cite{malware4,behavior3,pegasus} 
examine the source code or binaries of a mobile app, and match it 
against some predefined signatures of malicious behaviors (e.g.,
suspicious permissions usages~\cite{malware4} or control flow patterns~\cite{pegasus})
to identify potential user privacy leakage. Compared to dynamic approaches (including \ourtool), static techniques
are limited by their capabilities to model app's runtime behaviors, using approximations when computations are in-feasible, which introduce inaccuracies. For example, accurate and efficient alias analysis is still beyond the state of the art and 
pointer manipulation forces many static techniques to give up or
to approximate, resulting in overly weak properties that provides no guarantee.
As a result, static detection tools~\cite{malware4,behavior3,pegasus} are unable to accurately track how sensitive data is used in the program, thus are not be able to precisely identify sensitive information leakage. To combat these inaccuracies, Xiao et al.~\cite{xiao12:privacy} designed a new programming language that makes it easier to identify how private information is used inside applications. While their tool is able to accurately identify potential private information leakage, they are not able to reason about context-dependent privacy properties (e.g., malicious voice recorder secretly recording in the background). 
Our technique, \ourtool, overcomes static analyses' limitations by
monitoring the actual execution and enforces user privacy properties
at runtime. Doing so, \ourtool is able to enforce context-dependent privacy
policies and handle coding styles that stymie static analyses (e.g.,
indirect information flow by storing sensitive data into the file system and later retrieve it).

% \todo{not sure if JIF should be included, since nobody has used it on mobile apps aside from sparta}
%Third, static analyses~\cite{jif}
%often require programmers to write annotations or (partial) specifications.
%This may hinder their usability in practice. 
%With over 700k Android
%apps in the Google Play store as of 2013~\cite{NumAppStoreApps},
%a static analysis with substantial manual effort
%is less likely to be adopted.

%Jif~\cite{jif} is a language extension for Java that supports
%developer specifying information flow control and access control,
%which will be enforced at both compile time and run time. While
%it can provide strong privacy guarantees, it requires non-trivial
%human effort to annotate the application\todo{any data to show
%many annotations needed per app?}. With over 700k Android
%apps in the Google Play store as of 2013~\cite{NumAppStoreApps},
%such manual approach is less likely to be used in practice.
%the non-scalability of this approach is clearly a problem if applied to mobile apps. 


Dynamic enforcement techniques~\cite{behavior1,behavior2,aurasium,taintdroid},
as used in \ourtool, monitor the actual execution of an application and enforce the given policies
at runtime. Typical dynamic enforcement
techniques can run in a fully automated manner and produce no false positives. 
However, there is a major limitation that prevents existing
techniques being used in practice: they are either not-portable and incurring low overhead, or portable and incurring high overhead. For example, TaintDroid~\cite{taintdroid} leverages Android's just-in-time interpretation architecture and uses a modified interpreter to efficiently monitor the execution of Android applications. While its runtime overhead is not prohibitively large~\cite{taintdroid}, the need to alter the runtime environment prohibits its
large-scale adoption. Currently there are over 4000 unique Android devices used by the public and each one of them is running a custom variant of the Android OS, requiring modification from TaintDroid's developers. Furthermore, other mobile platforms, such as iOS and Windows Phones, use ahead of time compilation instead of just-in-time interpretation, which removes the need of using a interpreter at runtime. And Google just recently announced that Android will also be moving to a ahead of time compilation architecture (ART~\cite{art}), which directly compiles Android applications' Dalvik bytecode to native code during app installation, removing the need of Dalvik VM. While it is currently still in beta stage, Google is planing to fully transition to this framework in the future to reduce app start up time and increase UI responsiveness. Thus, a portable, platform-independent technique, such as \ourtool is highly demanded. %\ourtool statically modifies the Android applications on the Dalvik bytecode level, inserting dynamic checks and all the necessary helper libraries before app installation, thus is independent from the types of runtime system being used. 



Related to dynamic enforcement, Aurasium~\cite{aurasium}, using an inlined dynamic enforcement approach, packages the policy enforcement code into the target application before runtime, bypassing the need to modify the runtime environment. However, Aurasium is only able to monitor very coarse-grained control flow properties because it incurs significant performance overhead (up to 35\% when
enforcing a trivial policy). The high overhead prohibits the enforcement of more complex information flow properties like those require tracking sensitive information through the application execution, which are integral to protecting mobile user privacy.

%Furthermore, xxx \todo{app fense,user driven access control}  worked on deploying specific access control models on existing mobile systems. \todo{user driven access control} built an access control system of sensitive resources (such as microphones and GPS coordinates) by leveraging the implicit access granting when a user clicking on GUI buttons. They proposed a special GUI element, called ACG (access control gadgets) that dynamically grant the app access to camera when the user clicked on the ``Camera'' ACG button.

In comparison, our technique, \ourtool, addresses the limitation of existing
dynamic enforcement techniques by combining static optimization with inlined dynamic enforcement, making dynamic enforcement both portable and low overhead. Inlined dynamic enforcement eliminates the requirement of modifying the runtime environment, and is transparent to different types of runtime architecture, working on both just-in-time and ahead-of-time platforms. At the same time, \ourtool also statically optimizes the enforcement code, greatly reducing the number of additional instructions need to be added for enforcing a given policy. As reflected in our experiments, \ourtool
achieved much less overhead than other previous technique when monitoring policies containing information flow based properties.
As a result, \ourtool is both
portable, distinguishing it from TaintDroid, and lightweight, capable of enforcing the more complex information flow based properties that Aurasium is not able to.


\subsection{Dynamic Enforcement}

Dynamic enforcement is a well-established
technique to verify a system's runtime behaviors.
In addition to protect user privacy, dynamic enforcement
has also been widely used to ensure other types of policies,
such as memory/concurrency safety properties, and general correctness
properties. For example, JavaMOP~\cite{jin-meredith-lee-rosu-2012-tool-icse} is a parametric runtime
verification framework which supports multiple
logic formalisms. EnforceMOP~\cite{luo2013enforcemop} extends JavaMOP with
the ability to enforce properties in multithreaded programs.
Compared to existing dynamic enforcement techniques,
\ourtool is not a general framework; it is
 specifically designed for enforcing privacy policies, mostly containing multiple data flow properties, on mobile apps.
It considers several unique requirements of dynamic enforcement
on a mobile platform, such as the mobile platform has a higher requirement for efficiency,
practicality and portability of the protection mechanism due to relatively
constrained computing power, large number of mobile apps and diverse variants of the operating system.
%\sai{which is the difference between existing dynamic enforcement approaches and \ourtool? you need explain here.}

Software-based fault isolation (SFI)~\cite{sehr2010adapting,mccamant2006evaluating} is another well-known use of inlined dynamic enforcement that transforms an arbitrary program and guarantees the resulting program to satisfy a security policy of interest. Compared to \ourtool, which uses inlined dynamic enforcement to track sensitive information through the application execution, SFI mainly focuses on memory integrity and control flow integrity, such as efficiently restricting areas of memory that the program can read, write and jump to. Google's native client~\cite{yee2009native} is an example of using SFI to allow web browsers to securely execute an arbitrary piece of native code without the fear of being attacked.

There has also been a rich body of research in reducing the overhead of
dynamic enforcement in other domains. For example, 
Kim et al.~\cite{KimKCS09} improved the efficiency of tracking sensitive information flow through multiple processes.  
Purandare et al~\cite{purandare2013optimizing} proposed a family of
techniques to reduce the runtime overhead of dynamic enforcement tools
when multiple policies need to be enforced simultaneously. Their work is complementary to ours and might be used to further reduce \ourtool's runtime overhead under these situations.
%, which is also complementary, because \ourtool currently does not tracking inter-application information
%flows.
